Hi SJH,

I believe that with nonlinear kinematics and 3D (or more) complex paths that small, linear, smoothed segments will give the best results.

I'd rather not remove the option from the code.  It might be useful in some special cases.  Your code should be abe to force the arcs to linear option and so won't need to support the option.

Regarding TCPC: I believe the software achitecture should handle that correctly if the Kinematics module handles it properly.  I suppose that's what you are saying and working on.

Pure angular motion should consider the feed rate as degrees per minute and not move at maximum speed.  Is that what you are seeing?

Regards
TK




Quoting "Hardy Family hardy.woodland.cypress@... [DynoMotion]" <DynoMotion@yahoogroups.com>:

 

Hi Tom,
 

I am making extensive modifications to the interpreter and motion planner to support true 5-axis modes a-la Fanuc.
 

It turns out that all the code to generate and download arcs to the kflop is very complex to support when the kinematics are anything other than trivial, so for now I am requiring the "arcs to segs" flag to be set.
 

My question is whether there is any real benefit to supporting arcs natively.  Apart from presumably more efficient download and less USB bandwidth, is there any compelling reason to support them?  More smooth?  Would it be a bad idea for me to simply clean them out from the code?
 

Regards,

SJH
 

PS: I'm having to expand the functionality of the CKinematics class a lot.  Soft limits really need to be transformed through the kinematics.  It needs to be aware of tool offsets, g92, g54 offsets, current units and a whole bunch of other stuff.  There is also a new concept of feed rates in CAD space vs. actuator space.  For example, with tool center point control, feed rate is actual motion of tool relative to workpiece, even though the actuators might be moving much faster (but cancelling out some of their relative motion).  I haven't got this quite right yet, but getting there.  Seems to be too slow for "pure angular" moves, even though for TCPC the rotaries should move as fast as possible.

 

Currently, the code makes it a bit hard to "force" motion planner settings, since it just accesses the fields directly (no get/set functions).  So for now I just tuck away a copy of the "real" settings then overwrite the active ones to what I need.

I'm not planning on releasing this code so I don't mind maintaining my own branch - it's just a bit of a headache having to change stuff that won't be used, so I like to clean out stuff that obfuscates things - thanks to git that's easy.  If native arcs are only useful for "special situations" then I think I'll just rely on linear segments for now.  It's one less thing for our customers to fiddle with and break, too.

With TCPC, I don't really want the F word doing double duty as a linear or angular feed depending on the context.  In TCPC mode by definition there is no tool (control point) movement relative to the work if only changing the tool orientation.

The main problem is that there might be vastly different movement rate in two very similar circumstances:

F60

G0 X0Y0Z0A0C0 (move somewhere)

case 1:

G1 X0.001 A30

case 2:

G1 X0.000 A30

Case 1 is mixed angular/linear, so it rotates real fast because the small distance theoretically takes only 1ms, hence rotates 30,000 deg/sec.

Case 2 rotates at 2 deg/sec (pure angular at 60 deg/min).

I think it might be better for me to add a field to the motion planner settings to specify "max angular feed rate" rather than having to change the F number depending on whether there is a linear move or not.

Related question:

It's hard (and hazardous) to get this 5-axis stuff working on a real machine, so I would like to be able to use the MPG to advance the G-code program execution by small increments.  For example, each notch of the handwheel could be 10ms "time" increment.

So do you have any general suggestions as to the best approach for this?  I just don't want to go down the wrong track since there's a lot of work to be done.  No problem feeding in the MPG signal, but I'm not sure about the best way to "throttle" the segment download process, and how to split linear segments up into smaller time intervals.

Regards,

SJH

On Tue, Jan 26, 2016 at 8:48 PM, tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

I believe that with nonlinear kinematics and 3D (or more) complex paths that small, linear, smoothed segments will give the best results.

I'd rather not remove the option from the code.  It might be useful in some special cases.  Your code should be abe to force the arcs to linear option and so won't need to support the option.

Regarding TCPC: I believe the software achitecture should handle that correctly if the Kinematics module handles it properly.  I suppose that's what you are saying and working on.

Pure angular motion should consider the feed rate as degrees per minute and not move at maximum speed.  Is that what you are seeing?

Regards
TK

Quoting "Hardy Family hardy.woodland.cypress@... [DynoMotion]" <DynoMotion@yahoogroups.com>:

 

Hi Tom,
 

I am making extensive modifications to the interpreter and motion planner to support true 5-axis modes a-la Fanuc.
 

It turns out that all the code to generate and download arcs to the kflop is very complex to support when the kinematics are anything other than trivial, so for now I am requiring the "arcs to segs" flag to be set.
 

My question is whether there is any real benefit to supporting arcs natively.  Apart from presumably more efficient download and less USB bandwidth, is there any compelling reason to support them?  More smooth?  Would it be a bad idea for me to simply clean them out from the code?
 

Regards,

SJH
 

PS: I'm having to expand the functionality of the CKinematics class a lot.  Soft limits really need to be transformed through the kinematics.  It needs to be aware of tool offsets, g92, g54 offsets, current units and a whole bunch of other stuff.  There is also a new concept of feed rates in CAD space vs. actuator space.  For example, with tool center point control, feed rate is actual motion of tool relative to workpiece, even though the actuators might be moving much faster (but cancelling out some of their relative motion).  I haven't got this quite right yet, but getting there.  Seems to be too slow for "pure angular" moves, even though for TCPC the rotaries should move as fast as possible.

 

So are you saying this would best be done on the kflop, not on the PC side?  Then if I set the FRO to be proportional to the difference between the target time and the executed time (saturated to, say, 100%) it will work?

Interesting that it appears to be able to move backwards.  How much of the "done" path does the kflop retain?

Regards,

SJH

On Wed, Jan 27, 2016 at 10:30 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

Regarding case 1/case 2:  My understanding is that is how most systems are expected to operate.  However case 1 should be limited by the maximum rate of all the axes (and their accelerations) so it would rotate at the maximum rate possible (assuming that is less than 30,000 deg/sec).  And additionally in some kinematics systems those may well vary throughout the motion which is why breaking the motion into tiny segments helps optimize the motion fully.

Regarding debugging:  You should be able to use the functions SetFRO to advance forward and reverse through the path at your desired speed.  To move to a particular time you would need to command a positive or neg FRO until you get close and then slow down as you approach the target time.  CS0_TimeExecuted+CS0_t should tell you exactly where the tool is along the motion path in seconds.  You shouldn't need to do anything to throttle the download process.  That should happen normally to download only the amount of time specified in the buffer lookahead time.  The segments should also be automatically broken down into small segments.  Also the SetFRO (feedhold) will allow you to advance partially through a longer segment.

HTH
Regards
TK

On 1/26/2016 9:27 PM, Hardy Family hardy.woodland.cypress@... [DynoMotion] wrote:

 

Currently, the code makes it a bit hard to "force" motion planner settings, since it just accesses the fields directly (no get/set functions).  So for now I just tuck away a copy of the "real" settings then overwrite the active ones to what I need.

I'm not planning on releasing this code so I don't mind maintaining my own branch - it's just a bit of a headache having to change stuff that won't be used, so I like to clean out stuff that obfuscates things - thanks to git that's easy.  If native arcs are only useful for "special situations" then I think I'll just rely on linear segments for now.  It's one less thing for our customers to fiddle with and break, too.

With TCPC, I don't really want the F word doing double duty as a linear or angular feed depending on the context.  In TCPC mode by definition there is no tool (control point) movement relative to the work if only changing the tool orientation.

The main problem is that there might be vastly different movement rate in two very similar circumstances:

F60

G0 X0Y0Z0A0C0 (move somewhere)

case 1:

G1 X0.001 A30

case 2:

G1 X0.000 A30

Case 1 is mixed angular/linear, so it rotates real fast because the small distance theoretically takes only 1ms, hence rotates 30,000 deg/sec.

Case 2 rotates at 2 deg/sec (pure angular at 60 deg/min).

I think it might be better for me to add a field to the motion planner settings to specify "max angular feed rate" rather than having to change the F number depending on whether there is a linear move or not.

Related question:

It's hard (and hazardous) to get this 5-axis stuff working on a real machine, so I would like to be able to use the MPG to advance the G-code program execution by small increments.  For example, each notch of the handwheel could be 10ms "time" increment.

So do you have any general suggestions as to the best approach for this?  I just don't want to go down the wrong track since there's a lot of work to be done.  No problem feeding in the MPG signal, but I'm not sure about the best way to "throttle" the segment download process, and how to split linear segments up into smaller time intervals.

Regards,

SJH

On Tue, Jan 26, 2016 at 8:48 PM, tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

I believe that with nonlinear kinematics and 3D (or more) complex paths that small, linear, smoothed segments will give the best results.

I'd rather not remove the option from the code.  It might be useful in some special cases.  Your code should be abe to force the arcs to linear option and so won't need to support the option.

Regarding TCPC: I believe the software achitecture should handle that correctly if the Kinematics module handles it properly.  I suppose that's what you are saying and working on.

Pure angular motion should consider the feed rate as degrees per minute and not move at maximum speed.  Is that what you are seeing?

Regards
TK

Quoting "Hardy Family hardy.woodland.cypress@... [DynoMotion]" <DynoMotion@yahoogroups.com>:

 

Hi Tom,
 

I am making extensive modifications to the interpreter and motion planner to support true 5-axis modes a-la Fanuc.
 

It turns out that all the code to generate and download arcs to the kflop is very complex to support when the kinematics are anything other than trivial, so for now I am requiring the "arcs to segs" flag to be set.
 

My question is whether there is any real benefit to supporting arcs natively.  Apart from presumably more efficient download and less USB bandwidth, is there any compelling reason to support them?  More smooth?  Would it be a bad idea for me to simply clean them out from the code?
 

Regards,

SJH
 

PS: I'm having to expand the functionality of the CKinematics class a lot.  Soft limits really need to be transformed through the kinematics.  It needs to be aware of tool offsets, g92, g54 offsets, current units and a whole bunch of other stuff.  There is also a new concept of feed rates in CAD space vs. actuator space.  For example, with tool center point control, feed rate is actual motion of tool relative to workpiece, even though the actuators might be moving much faster (but cancelling out some of their relative motion).  I haven't got this quite right yet, but getting there.  Seems to be too slow for "pure angular" moves, even though for TCPC the rotaries should move as fast as possible.